Add ability to replace an item in a select view - #768

Hi, and thanks for the PR!

Could SelectView::get_item_mut() solve your use-case? Or SelectView::iter_mut if you need to access several items. In particular, you should be able to swap two items efficiently this way.

I'm fine adding this method, if only for the S: Into<StyledString> convenience factor. Wondering if it should be set_item vs replace_item, also, we could return the old value? 🤷

Could SelectView::get_item_mut() solve your use-case? Or SelectView::iter_mut if you need to access several items. In particular, you should be able to swap two items efficiently this way.

I'm not sure why, but I couldn't seem to get a mutable reference properly where the compiler allowed me to mutate the references. Then I realized that I didn't care about the old values and just need an efficient way to replace an item.

Wondering if it should be set_item vs replace_item

Great idea. I'm happy to make this change.

also, we could return the old value? 🤷

I like this as it feels consistent with other set_item type APIs. I gave it a shot, but it turns out to be a bit complicated to return the values within the Rc. I've still not really used Rc much and am running into many issues with working with the type and the compiler. If you have a chance, would you mind adding a suggestion in the diff so I could see how to do this?

I'm fine adding this method, if only for the S: Into convenience factor.

Do you mind explaining what you mean by this convenience? I'm not sure I understand this.

I like this as it feels consistent with other set_item type APIs.

I'd be fine with a set_item method with the same signature; "replace" somehow implies that we're getting the old value back (for example like in std::mem::replace).

I'm not sure why, but I couldn't seem to get a mutable reference properly where the compiler allowed me to mutate the references. Then I realized that I didn't care about the old values and just need an efficient way to replace an item.

Here's how you can currently get mutable references to the label and content of a SelectView, and replace them:

let mut v = cursive::views::SelectView::new()  
    .item_str("Foo")  
    .item_str("Bar"); 
                              
let (label, content) = v.get_item_mut(1).unwrap();
*label = "foo".into(); 
*content = "foooo".into(); 

Here label is a &mut StyledString, so we need to call .into() on a &str or String to get there. This is what I meant where I said a function taking <S: Into<StyledString>> would hide the conversion from the user for a small convenience gain.

If you have a chance, would you mind adding a suggestion in the diff so I could see how to do this?

Once way is to simply return the Arc<T> directly and let users unwrap it as needed:

pub fn replace_item<S>(&mut self, id: usize, label: S, value: T) -> (StyledString, Arc<T>)
where                                                                                        
    S: Into<StyledString>,                                                                   
{                                                                                            
    let prev = std::mem::replace(&mut self.items[id], Item::new(label.into(), value));       
    self.last_required_size = None;                                                          
    (prev.label, prev.value)
}                                                                                            

Another option is to use Arc::into_inner to try and take the item out of the Arc. It will fail (return None) if there's a clone of this Arc still alive - it could happen if the user calls SelectView::selection() for example, and stores the result. We could call that and return the previous value as (StyledString, Option<T>), but I think it's best to just return Arc and let the user deal with this possibility more explicitly.

@gyscos I did not disagree with your suggestions in your last comment, but have not had time to address it. I am also moving away from my usage of cursive so I won't have the time in the future. Thank you so much for creating cursive as it was a ton of fun to work with. Feel free to pick up this PR if you find it useful.

p.s. my move away from cursive is more so a movement from away from building my TUI app and not a critique of cursive.